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1 

SYSTEM AND METHOD OF DEFINING 
UNAUTHORIZED INTRUSIONS ON A COMPUTER SYSTEM 



TECHNICAL FIELD OF THE INVENTION 

The present invention relates generally to the field of computer systems, and 
more particularly to a system and method of defining unauthorized intrusions on a 
computer system. 

5 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This patent application is related to co-pending U.S. Patent Application, 
Attorney Docket No. 10014010- 1, entitled "METHOD AND COMPUTER 

1 0 READABLE MEDIUM FOR SUPPRESSING EXECUTION OF SIGNATURE FILE 

DIRECTIVES DURING A NETWORK EXPLOIT'; U.S. Patent Application, 
Attorney Docket No. 1O0I6933-1, entitled "SYSTEM AND METHOD OF 
DEFINING THE SECURITY CONDITION OF A COMPUTER SYSTEM 11 ; US, 
Patent Application, Attorney Docket No. 10017028-1, entitled "SYSTEM AND 

15 METHOD OF DEFINING THE SECURITY VULNERABILITIES OF A 

COMPUTER SYSTEM*'; U.S. Patent Application, Attorney Docket No, 10017055-1, 
entitled "NETWORK INTRUSION DETECTION SYSTEM AND METHOD"; U.S. 
Patent Application, Attorney Docket No. 10016861-1, entitled "NODE, METHOD 
AND COMPUTER READABLE MEDIUM FOR INSERTING AN INTRUSION 

20 PREVENTION SYSTEM INTO A NETWORK STACK"; U.S. Patent Application, 

Attorney Docket No. 10016862-1, entitled "METHOD, COMPUTER -READABLE 
MEDIUM, AND NODE FOR DETECTING EXPLOITS BASED ON AN 
INBOUND SIGNATURE OF THE EXPLOIT AND AN OUTBOUND SIGNATURE 
IN RESPONSE THERETO'*; US. Patent Application, Attorney Docket No. 

25 10016591-1, entitled "NETWORK, METHOD AND COMPUTER READABLE 
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MEDIUM FOR DISTRIBUTED SECURITY UPDATES TO SELECT NODES ON 
A NETWORK"; U.S. Patent Application, Attorney Docket No. 10014006-1, entitled 
"METHOD, COMPUTER READABLE MEDIUM, AND NODE FOR A THREE- 
LAYERED INTRUSION PREVENTION SYSTEM FOR DETECTING NETWORK 
5 EXPLOITS"; U.S. Patent Application, Attorney Docket No. 10016864-1, entitled 

"SYSTEM AND METHOD OF AN OS-INTEGRATED INTRUSION DETECTION 
AND ANTI-VIRUS SYSTEM"; U.S. Patent Application, Attorney Docket No. 
10002019-1, entitled "METHOD, NODE AND COMPUTER READABLE 
MEDIUM FOR IDENTIFYING DATA IN A NETWORK EXPLOIT'; U.S. Patent 

10 Application, Attorney Docket No. 10017334-1, entitled "NODE, METHOD AND 
COMPUTER READABLE MEDIUM FOR OPTIMIZING PERFORMANCE OF 
SIGNATURE RULE MATCHING IN A NETWORK"; U.S. Patent Application, 
Attorney Docket No. 10017333-1, aititled "METHOD, NODE AND COMPUTER 
READABLE MEDIUM FOR PERFORMING MULTIPLE SIGNATURE 

15 MATCHING IN AN INTRUSION PREVENTION SYSTEM"; U.S. Patent 
Application, Attorney Docket No. 10017330-1, entitled "USER INTERFACE FOR 
PRESENTING DATA FOR AN INTRUSION PROTECTION SYSTEM"; U.S. 
Patent Application, Attorney Docket No. 10017270-1, entitled "NODE AND 
MOBILE DEVICE FOR A MOBILE TELECOMMUNICATIONS NETWORK 

20 PROVIDING INTRUSION DETECTION"; U.S. Patent Application, Attorney 
Docket No. 10017331-1, entitled "METHOD AND COMPUTER -READABLE 
MEDIUM FOR INTEGRATING A DECODE ENGINE WITH AN INTRUSION 
i/t, i kCTTONois 1 cjvl ; u.s. rate lit Application, aikh iicy focKct jw jwi 
entitled "SYSTEM AND METHOD OF GRAPHICALLY DISPLAYING DATA 

25 FOR AN INTRUSION PROTECTION SYSTEM"; and U.S. Patent Application, 
Attorney Docket No. 10017303-1, entitled "SYSTEM AND METHOD OF 
GRAPHICALLY CORRELATING DATA FOR AN INTRUSION PROTECTION 
SYSTEM", 
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BACKGROUND OF THE INVENTION 

Computer system security issues have become extremely important as more 
and more computers are connected to networks and the Internet. Attacks on computer 
systems have become increasingly sophisticated due to the evolution of new hacker 
tools. Using these tools, relatively unsophisticated attackers can participate in 
organized atiacks on one or more targeted facilities. Distributed system attacks, such 
as denial of service attacks, generally target hundreds or thousands of unprotected or 
compromised internet nodes. 

In response to these more sophisticated attacks, new intrusion protection and 
detection systems are being developed and deployed to monitor and prevent attempts 
to intrude into computer networks. These intrusion protection systems typically have 
some knowledge of known vulnerabilities of the system they are guarding and 
properties of known intrusion attack tools. This knowledge is typically recorded in 
product documentation or stored in tables or databases specific to each system or 
product. However, there is no common or standard format or representation of the 
knowledge, which makes it difficult for the users or system administrators to access 
and use the information, as well as for the system developers to update the 
information. 

SUMMARY OF THE INVENTION 

In an embodiment of the present invention, a method of defining 
vulnerabilities of a computer system subject to attacks comprises die steps of 
specifying an identity of an attack, specifying at least one attribute of the specified 
attack, specifying at least one policy with respect to the specified attack, specifying at 
least one attribute of the specified policy, specifying a data signature of the specified 
attack to be detected. 

In another embodiment of the present invention, a method of defining 
vulnerability conditions of a system coupled to a global network according to a 
predetermined format comprises the steps of specifying a name of an attack, 
specifying a data signature of the specified attack to be detected, specifying a policy 
definition with respect to the specified attack, and specifying at least one attribute of 
the specified policy definition. 
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In yet another embodiment of the present invention, a system of describing 
possible attacks on a computer system according to a predetermined format comprises 
a vulnerability description file containing a definition of at least one attack and a 
definition of at least one policy for the attack. The system also comprises an 
5 interpreter operable to parse the attack and policy definitions in the vulnerability 
description file and organize the parsed definitions pursuant to a predetermined 
format, and a data storage of the parsed and organized attack and policy definitions 
for access by one or more intrusion detection applications. 

10 

BRJEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present invention, the objects and 
advantages thereof reference is now made to the following descriptions taken in 
connection with the accompanying drawings in which: 
15 FIGURE 1 is a simplified block diagram of a typical distributed attack on a 

computer system; 

FIGURE 2 is a block diagram of a computer system deploying network-based, 
host- based and inline intrusion protection systems within which the present invention 
may be implemented; 

20 FIGURE 3 is a simplified block and data flow diagram of an embodiment of a 

vulnerability description system according to the teachings of the present invention; 
and 

FIGURE "4" is" a~~ database diagram ~of an - embodiment - trf" it vulnei ability 
description database storing information from a vulnerability description file of the 
25 present inve ntion . 

DETAILED DESCRIPTION OF THE DRAWINGS 

The preferred embodiment of the present invention and its advantages are best 
30 understood by referring to FIGURES l through 4 of the drawings, like numerals being 
used for like and corresponding parts of the various drawings. 
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FIGURE ] is a simplified arrangement common in distributed system attacks 
on a target 30 machine. An attacker machine 1 0 may direct execution of a distributed 
attack by any number of attacker client machines 20a-2Gn by any number of 
techniques such as remote control by "robot" applications. Client machines, also 
referred to as "zombies" and "attack agents" 20a- 20n, are generally computers that 
are accessible by the public via the Internet or otherwise compromised in some 
manner. Client machines 20a-20n may be geographically distributed. A distributed 
attack may be launched from client machines 20a-20n by a command issued on 
attacker machine 10, Numerous types of distributed attacks may be launched against 
a target machine 30 such as denial of service attacks. The target machine 30 may 
become so overloaded from the attacks that it can no longer service and respond to 
legitimate requests. 

FIGURE 2 is a diagram of an embodiment of a comprehensive intrusion 
protection system (IPS) employing networkbased, host-based and inline intrusion 
protection systems, such as Hewlett-Packard Company's AttackDefender. Network- 
based intrusion protection systems are generally deployed at or near the entry point or 
even boundary of a network, such as a firewall. Network-based intrusion protection 
systems analyze data inbound from the Internet and collect network packets to 
compare against a database of various known attack signatures or bit patterns. An 
alert may be generated and transmitted to a management system that may perform a 
corrective action such as closing communications on a port of the firewall to prevent 
delivery of the identified packets into the network. Network-based intrusion 
protection systems generally provide real-time, or near reakime, detection of attacks. 
Thus, protective actions may be executed before the targeted system is damaged. 
Furthermore, network^based intrusion protection systems are particularly effective 
when implemented on slow communication links such as ISDN or Tl Internet 
connections. Moreover, network-based intrusion protection systems are easy to 
deploy. 

Host-based intrusion protection systems, also referred to as "log watchers " 
typically detect intrusions by monitoring system logs. Generally, host based intrusion 
systems reside on the system to be protected. Host -based intrusion protection systems 
generally generate fewer "false-positives," or incorrect diagnoses of an attack, than 
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network-based intrusion protection systems. Additionally, host-based intrusion 
protection systems may detect intrusions at the application level, such as analysis of 
database engine access attempts and changes to system configurations. Log-watching 
host- based intrusion protection systems generally cannot detect intrusions before the 
5 intrusion has taken place and thereby provide little assistance in preventing attacks. 

Log- watching host-based intrusion protection systems are not typically useful in 
preventing denial of service attacks because these attacks normally affect a system at 
the network interface card driver level. Furthermore, because log-watching host- 
based intrusion protection systems are designed to protect a particular host, many 
10 types of network-based attacks may not be detected because of its inability to monitor 

network traffic. A host -based intrusion protection system may be improved by 
employing operating system application program interface hooks to prevent intrusion 
attempts. 

Inline intrusion protection systems comprise embedded intrusion protection 

15 capabilities into the protocol stack of the system being protected. Accordingly, all 

traffic received by and onginating from the system will be monitored by the inline 
intrusion protection system. Inline intrusion protection systems overcome many of 
the inherent deficiencies of networkbased intrusion protection systems. For example, 
inline intrusion protection systems are effective for monitoring traffic on high-speed 

20 networks. Inline intrusion protection systems are often more reliable than network 

based intrusion protection systems because all traffic destined for a server having an 
inline intrusion protection system will pass through the intrusion protection layer of 
the protocol iftackr Add i tio n al l y , -■ a* attaek- ma^be- prevented bec«^-aa itUine 
intrusion protection system may discard data identified as associated with an attack 

25 rather than pass the data to the application layer for processing. Moreover, an inline 

intrusion protection system may be effective in preventing attacks occurring on 
encrypted network links because inline intrusion protection systems may be 
embedded in the protocol stack at a layer where the data has been decrypted. Inline 
intrusion protection systems is also useful in detecting and eliminating a device from 

30 being used as an attack client in a distributed attack because outbound, as well as 

inbound, data is monitored thereby. 
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Referring to FIGURE 2, one or more networks 100 may interface with the 
Internet 50 via a router 40 or another suitable device. In network 100, for example, 
two Ethernet networks 55 and 56 are coupled to the Internet 50 via router 40. 
Ethernet network 55 comprises a firewall/proxy server 60 coupled to a web-content 
server 6 J and a file transport protocol content server 62, Ethernet network 56 
comprises a domain name server (DNS) 70 coupled to a mail server 71 ? a database 
sever 72 , and a file server 73. Network- based intrusion protection systems deployed 
on dedicated appliances 80 and 81 are disposed on two sides of firewall/proxy server 
60 to facilitate monitoring of attempted attacks against one or more nodes of network 
100 and to facilitate recording successful attacks that successfully penetrate 
firewall/proxy server 60. Network intrusion protection devices 80 and 81 may 
respectively comprise (or alternatively be connected to) databases 80a and 81a 
containing known attack signatures. Accordingly, network intrusion protection 
device 80 may monitor all packets inbound from Imernet 50. Similarly, network 
intrusion protection device 81 monitors and compares all packets that passed by 
firewall/proxy server 60 for delivery to Ethernet network 56, 

An IPS management node 85 may also be comprised in network 100 to 
facilitate configuration and management of the intrusion protection system 
components comprised in network 100. In view of the deficiencies of host-based and 
network- based intrusion protection systems, inline and/or host-based intrusion 
protection systems may be implemented within any of the various nodes of Ethernet 
networks 55 and 56, such as node 85. Additionally, management node 85 may 
receive alerts from respective nodes within network J 00 upon detection of an 
intrusion event. 

Preferably, network intrusion protection devices 80 and 81 are dedicated 
entities for monitoring network traffic on associated links of network 100. To 
facilitate intrusion protection in high speed networks, network intrusion protection 
devices 80 and 81 preferably comprise a large capture RAM (random access memory) 
for capturing packets as they arrive on respective Ethernet networks 55 and 56, 
Additionally, it is preferable that network intrusion protection devices 80 and 81 
respectively comprise hardware-based filters for filtering high-speed network traffic. 
Filters may be alternatively implemented in software at a potential loss of speed and 
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corresponding potential losses in protective abilities provided thereby to network \ 00. 
Moreover, network intrusion protection devices 80 and 81 may be configured, for 
example by demand of IPS management node 85, to monitor me or more specific 
devices rather than all devices on a network. For example, network intrusion 
protection device 80 may be instructed to monitor only network data traffic addressed 
to web server 6L Hybrid host- based and inline- based intrusion protection system 
technologies may be implemented on all other servers on Ethernet networks 55 and 56 
that may be targeted in a distributed system attack. A distributed intrusion protection 
system such as the one described above may be implemented on any number of 
platforms, such as UNIX, Windows NT, Windows, Linux, etc, 

FIGURE 3 is a simplified data flow diagram of an embodiment of the present 
invention. A vulnerability description language (VDL) file 200 is preferably a text 
file having a standard format that specifies security and/or vulnerability descriptions 
of one or more computer systems. VDL file 200 comprises a collection of 
hierarchical security specifications, which are defined by product, category, and group 
definitions. For example, VDL file 200 may comprise these levels of definition (with 
the security definition details removed): 

B£GlM_£ECURITY_PRODUCT: IntruderDetect 
BEG I N_S E CUK.I Tf ^CATEGORY : TROJANS 

BEGIN_POLICY_GROUP ; " \lntrus ion Detection Policy \ Trojan Horses\TCP -Based ■ 
BEGIH_jSECURITY_JDEF ; HackOffice 
END_SECURITY_DEF 

EMD_SBCUR ITY_DEF 
END_POLICY_GROUP 

BEGlN__POLICY_GROUP r n \lntjrusion Detection Policy\Trojan Horses\UDP -Based" 
BEGIH_SECDRITY_DEF : SackOr i £ i ce 
END^SECURI TY_D£F 
END_POLI CY_GROUP 
END_SECURITY_CATEGOftY 
END_S ECJRI TY_PRODUCT 
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Further details of the VDL format are set forth below, VDL file 200 may describe the 
vulnerability of a computer system, how to test for its presence, how to report the 
detection of a vulnerability, and how to repair the vulnerability. For example, a 
computer system may have a vulnerability of allowing network peers to assist in 
managing NetBios name conflicts with an unauthenticated protocol that is subject to 
spoofing. When used by a network intrusion detection system or network protection 
system, VDL file 200 preferably comprises a description of attack data signatures. 
Attack signatures are patterns in the transmitted data or network frames that are 
indicative of an attack such as the ping of death. 

VDL file 200 may be read and compiled by a VDL interpreter 202, which 
parses the descriptions therein and organizes them into one or more tables in a 
configuration database 204. Alternatively, an application program may compile or 
interpret VDL file 200 upon start up or on-the-fly and store the security definition 
information in memory. An example of how configuration database 204 may be 
organized is shown in FIGURE 4, described in more detail below. VDL interpreter 
202 may organize the data in configuration database 204 according to a format and 
layout specified by a maker of application programs 206 that use its data, such as 
intrusion detection applications 207 and vulnerability assessment applications 208, 
Intrusion detection applications 207 and vulnerability assessment applications 208 
monitor network data received by a network driver 210 from a network 212 according 
to the security definitions stored in configuration database 204. Applications 207 and 
208 may also interface with host operating system 209 and host applications 21 1. 

There are four groups of information in the security definitions set forth in 
VDL file 200. The first group comprises descriptions of a security condition, such as 
a vulnerability or an attack, and how to repair or prevent it. These standard 
description format strings comprise PLATFORM, SEVERITY, DESCRIPTION, 
BRIEFJ>ESCRIPTION, EXPLANATION, AUTO.FIX.DESCRJPTION, and 
MANUAL JFIXJ2ESCRJPTION. In VDL, there is also a concept of platforms. A 
security definition, as well as its policy items, can be defined for one or more 
platforms. Preferably, when the security product is running on a specific platform, 
only security definitions assigned to that particular platform are enforced, and only 
policy items assigned to that particular platform are presented or reported to the user. 



100 I 7029-1 



10 

Alternatively, a network administrator may prefer to receive reports regarding 
multiple platforms or nodes in the network. The platform definition typically 
describes the type of system the security product application is rurming on, such as a 
black box appliance, an agent running on a server, etc. The actual text displayed to 
the user or administrator of the security product is stored within the VDL, making 
translation a fairly simple issue. This text is used both in the user interface as well as 
on printed reports. 

The second group of security definitions comprises strings describing how 
audit or detection results are to be presented. These standard vulnerability description 
strings may comprise, for example, GENERAL_RESULTS_TEXT, 
BEGIN_INTERMED1ATE_RESULTS_TEXT_DEF, 

END„1NTERMEDIATE_RESULTS_.TEXT_DEF, and 
BEG1N_DETAILED_RESULTS_TEXT_DEF 

ENDJDETAILED_RESULT3_TEXT_DEF. VDL preferably provides a three^iered 
results reporting model: general results, intermediate results, and detailed results. 
General results are summary-level and single- line strings. Intermediate and detailed 
results are usually presented in a tabular format, with the columns defined in the 
VDL. Results are usually presented in the application's user interface as well as in 
reports. It is up to the security product application to determine which level of 
reporting is desired for which particular situation. 

The third group of security definitions comprises one or more 
BEGINJPOLICYJDEF and ENDJPOLICY_DEF sections, which provide policy 
~serting5~1br vulnerability or intiusion. -Pofcey items are - u s er - co n figurable 
parameters for the particular vulnerability or intrusion. Usually the policy items 
define how the vulnerability or intrusion is detected, reported or repaired. 

The fourth group of security definitions comprises definitions that specify how 
an intrusion is to be detected. This group may comprise zero or more 
BEGIN_SIGNATURE_DEF and END_SlGNATURE_DEF sections, The data frame 
bit or byte pattern indicative of a known attack is defined in this section. For 
example, the signature definition for a typical ping of death distributed attack may be 
defined by: 
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if {(icmp) && (65535 < ((ip[2:2] - «tp[0:l] & QxOf) * 4)) + ((ip[:2] & OxlfTf) * 8))))) 

Optionally, a PLUGIN keyword may be used to delegate the detection task to another 
application module. The PLUGIN keyword provides the name of a DLL 
(dynamically linked library) or object that will handle recognition of the intrusion. 
The DLL is passed all packets matching the S1GNATURE„DEF sections. 

Hereinafter is a more detailed description of VDL standard format for 
describing computer system vulnerability. Heretofore, vulnerability or intrusion 
information of computer systems are typically contained in Read Me files, user 
documentation, databases or other locales in non-standard formats. These files or 
manuals are typically only readable by humans. The VDL descriptions in the VDL 
files of the present invention may be read by humans as well as computer programs 
because it provides a standard syntax and format. In the description below, text 
within angled brackets are explanations or descriptions that are not taken literally, text 
not within angled brackets should be taken literally, and keywords in all caps are 
mandatory unless specifically labeled as optional. The following shows the general 
structure and format of a VDL file according to the teachings of the present invention: 

BEG1N,SECURITY_PK0DUCT: <product name> 

BEGIN JPOLICYJ3ROUP: <policy folder name> 
BEGIN_POLICY_DEF: <policy item name> 
<policy properties> 

ENDJ>OLICY_DEF 
END_POLICY_GROUP 



BEGIN_SECURITY_C ATEG ORY ; <category name> 
BEGIN_POLICY_GROUP: <policy folder name> 

BEGIN J>OLICY_DEF: <policy item name> 
<policy properties> 

END_POLlCYJ>EF 

B EGIN_SECURITY_DEF : Security item name> 
<security item properties> 

BEGIN J>0LICYJDEF: <policy item name> 
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<poiicy propertied 
END_POLICY_DEF 

BEGIN_SIGNATURE_DEF: <pohcy item name> 
<if statements 

END_51GNATURE_DEF 

END_SECURITY_DEF 

END^POLICY^GROUP 
END„SECURJTY_CATEGORY 

* * * 

END_SECURJTY^PRODUCT 

The product definition section encapsulates all other sections related to a 
product. A VDL file can contain multiple product definition sections. A product 
definition section is used to specify the name of a security product such as an 
intrusion detection application, intrusion protection application, or vulnerability 
scanner. The preferred format for product definition is: 

BEGIN_SECURJTY_PRODUCT : <product name> 

<Policy Group Definition sections> 

<Category Definition sections> 
END^SECURITYJPRODUCT 

The product definition section is delineated by the BEGIN_SECURITY_PRODUCT 
keyword and a matching END_SECURITY_PRODUCT keyword. The section can 
contain multiple policy group definition sections and multiple category definition 
sections. 

The policy group definition section associates a group of policy item 
definitions or security item definitions with a policy folder. One or more policy group 
definition sections can appear within a product definition section or a category 
definition section. The preferred format is: 
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BEGIN^POLICY_GROUP: <policy folder name> 

<Policy item Definition sections> 

<Security Item Definition sections> 
ENDJ>OLICYj3ROUP 

The policy folder name specifies the full name of the folder that contains the 
encapsulated policy items and security items. Ajti example is: 

BEGIN^POLICY^GROUP: 'tfvfy Policj/Wy Policy Items" 

In this example all encapsulated policy items or security items will be placed in the 
"My Policy Items" subfolder within the "My Policy" parent folder. 

The category definition section associates a group of related security items and 
policy items. One or more category definition sections can appear within a product 
definition section. A category definition section can contain one or more policy group 
definition sections. The preferred format according to the present invention is: 

BEGIN_SECURITY_CATEGORY : Category name> 

<Policy Group Definition sections> 
END_SECURITY_CATEGORY 

The policy item definition section is used to describe all properties related to a 
policy item. Policy items typically correspond to parameters that are required to 
perform an audit or to detect an intrusion. However, there are many policy items that 
provide generic settings such as schedule configuration and e-mail configuration. 
Policy items typically have default values, which may be revised by the user. The 
data for a policy item is stored in a database. The user's policy consists of the entire 
collection of policy items in the database. 

BEGTM_POLICY_DEF: <policy item name> 

<platform> //Optional. Default is ALL 

<pohcy item brief description> 
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<poUcy item expIanation> 
<type> 

<defauh value> 
<lower bound> 
<upper bound> 
<num chars> 
<exctude char set> 
<include char set> 
<list> 
<prog id> 
<fix only flag> 
END_POLICYJ)EF 



// Optional Valid only if <typc> = NUMBER 
// Optional Valid only if <type> = NUMBER 
// Optional, Default is 256 

// Optional. Mutually exclusive with <include char set> 
// Optional. Mutually exclusive with <exclude char set> 
// Mandatory if <type> = DROPLIST 
// Mandatory if <type> = CUSTOM 
// Optional 



The <policy item narne> specifies the name of the policy item. The name 

15 format preferably does not allow white space characters (i.e. blanks or tabs). The 
<platform> specifies the computer platform that applies to the policy/security item. 
Exemplary platforms may comprise AGENT, APPLIANCE, MOBILE, 
AGENT_AND_APPLIANCE, or ALL (default). The piatform specification may not 
be mandatory. The <policy item exp!anation> contains text that describes the policy 

20 item and may be used in reports and/or on screen help dialog windows. The <policy 
item explanation> may contain a few sentences that describe the policy item. This 
description may be used in reports and may also be used to provide additional 
onscreen help; " The <type>" field" specifieTTfre" type ofpoticy lteim;"wtrtc1rTTiay specify 
CHAR, NUMBER, DROPLIST, CHECKBOX, or CUSTOM types. The CHAR type 

25 indicates that the policy item requires an edit field, the NUMBER type indicates that 
the policy item requires an edit field for numerals, the DROPLIST type indicates that 
the policy item requires a dropdown list of items, the CHECKBOX indicates that the 
policy item requires a checkbox, and the CUSTOM type indicates that the policy item 
requires a custom dialog box to retrieve input from the user. The <defauh value> 

30 field specifies the default value associated with the policy item. The default value 
format is as a string surrounded by double quotes. The <lower bound> specification 
is valid only when <type> is NUMBER and specifies the lower bound tor the range of 
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valid numbers associated with the policy item. Preferably, the user will not be 
allowed to enter numbers less than <lower bound>. if <lower bound> is specified 
then <upper bound> should also be specified. Similarly, the user will not be allowed 
to enter numbers greater than <upper bound>. The <num chars> specifies the 
maximum number of characters allowed in the edit box associated with a policy item. 
The <exciude char set> specifies characters that are not allowed in the edit box 
associated with a policy item. The <include char set> specifies characters that are 
allowed in the edit box associated with a policy item. The <list> field specifies items 
to be contained in the dropdown Hstbox. The <prog id> specifies the Prog ID of a 
COM object that can display a dialog box used to retrieve the custom policy data 
when <type> is CUSTOM. The <fix only flag> is used to indicate that the policy 
item is for fixing a security problem and not auditing it. If this flag is not set then the 
policy item is for fixing a security problem as well as auditing it. 

The security item definition section preferably describes all properties related 
to a security item. Security items typically are the subject matter being audited or 
detected. For example, a security item may be the ping of death attack to be detected, 
or ReleaseNetBiosName vulnerability to be audited. 

BEGIN_SECURJTY_DEF : <security item name> 

<piatform> //Optional. Default is ALL 

<security item explanation> 
<security item brief description> 
<severiry> 

<autofix description> 
<autofix past tense description> 
<autofix waming> 
<manual fix descriptors 
<fix description query> 
<general results text> 
<detailed display option> 

<enab!ed> // Optional. Default is ] (enabled) 

<Detaikd Results Text Definition section> // Optional. 
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<Irtterrnediate Results Text Definition section> // Optional 



<Policy Item Definition section> // Optional 

<Signature Definition section> // Optional 

<Phjgin> // Optional 

5 <Auditor> // Optional 

END_SECURITY_DEF 



The <security item name> specifies the name of the security item and 
rxeferably does not contain white spaces. The <security item brief description> is 

1 0 preferably a mandatory field and specifies text that is displayed in an editor that a user 
may use to edit or revise the policy item data. This editor may be a dedicated policy 
editor that is a component of a graphical user interface. The text should briefly 
describe the security check to be performed. For example, BRIEF_DESCRiPTION: 
"Check administrator account name". The <security item explanation> field is used 

15 to specify text that explains why the specified security item is an issue and how 
hackers can exploit the vulnerability to damage the system, for example. The 
<severity> field specifies the severity of a potential vulnerability or attack on a 
predetermined scale, such as I to 5. The <autofrx description> contains a brief 
description of what will be fixed by an autofix feature of a vulnerability assessment 

20 system, such as the INTELUFIX feature of the SFPROTECT system. This 
description can contain one or more siring format specifiers such as %s. Whenever 
the system encounters a % in the <autofix description> it will replace it with the 
parameter returned" from the* <frx description query>v "Prefer ably," the" order of the" 
parameters returned by the query will be the order in which they are inserted in the 

25 <autofix description> string. The <autofix past tense description> field contains a 
brief description of what has been fixed by the autofix feature. This description can 
contain one or more string format specifiers (i.e. %s). Whenever the system 
encounters a % in the <autofix past tense description> it will preferably replace it 
with the parameter returned from the <fix description query>. The order of the 

30 parameters returned by the query will be preferably the order in which they are 
inserted in the <autofix past tense description> string. For example, the <autofix past 
tense description> field may specify "Fix has changed the administrator account name 
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to "%s'\" The <autofix warning> is used to contain a brief warning to the users to 
remind them of the consequences of performing an automatic remedy to the specified 
security item. For example, AUTO_FIX_ WARNING: "Record the new name of the 
administrator account and be sure to corrununicate the new name to the other 
administrators. 11 If the security item can be fixed, this field is preferably mandatory. 
The <flx description query> field specifies a query used to format an autofix 
description string. For example, FIX_DESCR1PTI0N_QUERY: "SELECT 
PolicySettings.Policyltem FROM Pol icy Settings WHERE 

{{(Po]icySettings.SecurityID)=1000)) ,, applies to: <autofix description> and <autoflx 
past tense description^ 

The <manual fix description> field is used to specify a step- by-step 
description of how to manually fix the security problem. For example, 
MANUAL J1XJDESCRIPTION; "If Internet Information Server has been installed 
on the Operating System volume, it will have to be uninstalled and reinstalled on an 
alternate volume. If a virtual directory has been set up on the Operating System 
volume, use the Microsoft Management Console to drop and then create a new virtual 
directory on an alternate volume. For more information about virtual directories, see 
the Product Documentation for the Windows NT 4.0 Option Pack." This field is also 
preferably mandatory. The <general results text> field contains a string to be 
displayed in the general results window. For a vulnerability scanner, it should specify 
the results of a security audit; for an intrusion protection system, it should contain a 
general description of the attack that was detected. For example, M %s of %s files or 
subdirectories have failed the permissions check." may be used as the <general results 
text> string for security item used to check file permissions- This allows the user to 
be informed of the status of the audit The <detailed display option> field preferably 
specifies one of three levels of detailed display to be used by the security item, 
comprising no detailed display, normal level of details, and optimized detailed 
display. The <enabled> field specifies whether or not the security item is initially 
checked in the policy editor. Security items are enabled by default. The <plugin> 
field specifies name of a security plug-in to associate with a security item. A plugin is 
an object which can be dynamically loaded into the system. The piugin name has the 
format: DLLName.ObjectName, 



100 17029-1 



18 



The signature definition section contains expressions describing the tell tale 
data pattern of a networkbased attack. One or more <if statements can be used to 
describe an attack signature. The signature definition section can only exist within a 
security item definition section. There can only be one signature definition section 
per security item definition section. The general format and syntax of the signature 
definition section is: 

BEGIN_SIGNATURE_DEF 
<if> 

<signature expre$sion> 
DIRECTION: INBOUND 
<endi£> 
END_SIGNATURE__DEF 

Each security definition can have multiple signature expressions: 

BEGINJ$IGNATURE_DEF 
<if> 

<signature expression> 
DIRECTION: INBOUND 
<endif> 

<&>~ 

<signature expression> 
DIRECTION: INBOUND 
<endif> 
<if> 

<signature expression> 
DIRECTION: OUTBOUND 
<endif> 
END_SIGNATUREJDEF 
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An example is shown below: 

BEGIN_SIGNATURE_DEF 

if ( (udp) && (ip[19: 1] =0 1| ip[]9:l] - Oxff) && 
<udp[2:2] =7 || udp[2:2] =17 1| udp[2:2] - ]9)) then 
ACTION: LOG_FRAME 
DIRECTION: INBOUND 

Endif 

END_SIGNATURE_DEF 

The Signature expression> field describes the conditions) for detecting a network 
based attack. The signature expression can span multiple lines and must have the 
following general syntax: 

If <if expression> then 
ACTION: <action> 
DIRECTION: <direction> 

endif 



or Signature expTession> may be <if expression :: (<if expression> ) | ( <operand> 
<operato r2 > <operand>), or <if expression> :: (<if expression> ) | 
(<operandxoperator i>), where < operator^ is a unary operator and <operator2> is a 
binary operator. Possible unary operators comprise bitwise complement and NOT. 
Possible binary operators comprise logical, arithmetic, and bitwise operations. 
<operand> is expressed by <protocol expression> | <literal number> <po!icy 
variable^ where protocol expression> is <protocol>{ [offset: byte length]}. 
<proloco> may comprise TCP, ICMP, UDP, IP, MAC, IGMP, GCP,PUP, RAW, and 
other protocols. The field <literal number> comprises any "C" style numeric 
expression, such as OxffnT , 100. The <policy variabte> field comprises $: <policy 
item name>. The <action> field specifies the action to be taken when the signature 
expression evaluates to tree. The <action> field may specify LOG_FRAME (log 
frame each time the signature expression evaluates to true) and/or 



10037029-1 

20 

INCREMENT JTOUNTER (a counter will be incremented each time the signature 
expression evaluates to true). The <direction> field specifies the direction to apply 
the signature expression to indicate whether the data flow is INBOUND and/or 
OUTBOUND. 

5 The detailed results text definition section is used to specify the formatting of 

the detailed results table. This information is used by a DetaiiedResultsGrid control 
to determine how to format the data for the detailed results view. The general format 
is: 

10 BEGIN_DETAILED__RESULTS_TEXT_DEF 
<header cols> 
<ceiltext„cols> 
END_DET AILED JR£SULTS_TEXT_DEF 

15 The intermediate results text definition section preferably specifies the 

formatting of the intermediate results table. This information is used by the 
DetaiiedResultsGrid control to determine how to format the data for the intermediate 
results view, A general format is: 

20 BEG [N_INTERMED1ATE_RESULTS JTEXTJ3EF 
<header cols> 
<ceiltext_cols> 

25 The <header cols> field is used to specify the text for column header of a display 
table. For example, the following <header col> fields specify the text to be displayed 
in the first and second column headers of the detailed display table. In this example, 
the column header for the first column would be displayed as "User Name". The 
second column header would be displayed as "Last Logon". 



30 



BEGIN_DETA1LED_RESULTS_TEXT_DEF 
HEADER.COLl :"User Name" 
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CELLTEXT_COL I : "%s" 
HEADER_COL2: T, Last Logon* 
CELLTEXT_COL2:"%s" 
END_DETAJLED_RESULTS_TEXT_DEF 

This would result in: 



User Name 
Fred 


Last Logon 

7/1/99 


John 


' 6/24/99 


Jim 


7/9/99 



The <celltexLcols> field specifies the text to be used in each cell of a display table. 
The string can contain string format specifiers (i,e, %s). If <detailed display option> 
is NORMAL display, the display string will come from the AuditObject fields of from 
a joined query of the DetailedAuditResults table and the DeiailedAnditResnltsDetail 
table. If <deiailed display option> is OPTIMIZED display, the CELLTEXT_COL 
field is ignored. The information to be displayed is written directly into the 
AuditObject field in he DetailedAuditResults table. The tab characters in the 
AuditObject field are used as delimiters for placing text in the proper column, 

The VDL file, the syntax and format of which is set forth in detail above, is 
preferably read and parsed to organize the vulnerability information specified therein 
into a form that can be accessed and used by security applications such as 
vulnerability scanners, intrusion detection systems and intrusion protections systems. 
FIGURE 4 is an exemplary relational database diagram of a vulnerability database 
that may be used to store the data obtained and parsed from VDL file 200 (FIGURE 
3). Recall from the foregoing that the VDL file preferably contains four types of 
specification: 

1) specification of the vulnerability and attack, and how to prevent or repair it 

2) specification of how the audit or detection results should be presented or 
reported 

3) specification of what policy or settings govern a particular vulnerability or 
intrusion 
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4) specification of how to recognize an intrusion 

The category 1 information supplied in the VDL file are stored in a security 
definitions table 300. Each security item is assigned a unique security identifier 
(SecuritylD) which is used to index and link the information in several other tables m 
the database to security definitions table 300. There is typically a one-to-one 
correspondence from a security item specification in the VDL file to a data field in 
security definitions table 300, Information from category 2 on how results should be 
presented and displayed are stored in several tables, including 
DetaileoV^uoUtResultsDetaiuOisplayStrings table 302, 

Detailed AuditResultsDisplay Strings table 3 04, IntermediateDetailDisplay Strings 
table 306, and GeneralAuditResultsDisplayStrings table 308. Information from 
category 3 on policy settings are stored in several tables, including PolicyName table 
310, PolicySertings table 312, PolicyltemAttributes table 314, and Policy table 316. It 
may be seen that each policy item is assigned a policy item identifier, which is used to 
link PolicyltemAttributes table 314 to PolicySettings table 312. All policy setting 
tables 310-316 are also linked to security definitions table 300 by SecuritylD. 
Information in category 4 is stored in SignatureDefmitions table 318 and Plugln table 
320, both of which are preferably linked to security definitions table by SecuritylD. 
A PlatformDefinition table 322 is further used to store the computer platform 
information identified in the security item definition description of the VDL. 
Furthermore, informalion related to the security product specification is stored in 
j^urityt^ table 326. Tables *24 and ; 326 

are indexed and linked to security definitions table 300 via the SecuritylDCategory 
data entry and an identifier, ProductID, assigned to the security product. 

The vulnerability information stored in the database is accessible by an 
number of security product applications, such as intrusion detection systems and 
vulnerability scanners. A graphical user interface may be used to facilitate entry of 
vulnerability data in the VDL file and also to provide on-screen reporting of detection 
and audit results according to the information specified in the VDL file. 

According to the present invention, a standard text-based syntax and format 
for describing a computer system's security condition is used so that users may easily 
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view and update and modify the description to adapt to changing conditions. 
Furthermore, because of the standard syntax, computer applications may be developed 
to read and process the information in the vulnerability description file, such as 
parsing the data to store into a relational database or to store the data in memory 
during application execution. The standard syntax and format of the present invention 
enables uniformity and inter-operability between various applications. 
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WHAT TS CLAIMED IS: 

1. A method of defining unauthorized intrusions on a computer system 

(30) subject to attacks, comprising: 

specifying an identity of an attack (300, 324); 
5 specifying at least one attribute of the specified attack (318); 

specifying at least one policy with respect to the specified attack (310, 312, 

314); 

specifying at least one attribute of the specified policy (314); 
specifying a data signature of the specified attack to be detected (318); and 
t o using the above-specified information to detect unauthorized intrusions (207). 

2. The method, as set forth in claim 1, further comprising specifying a 
computing platform of the computer system (322) on which the attack is to be 
detected. 

15 

3 . The method, as set forth in claim 1 , further comprising: 
specifying a security category (324) of the specified attack; and 
specifying at least one policy group (300, 310, 312) with respect to the 
specified attack. 

20 

4. The method, as set forth in claim 3, further comprising specifying a 
computing platform of the computer system <322> with respect tfr the security 
category. 

25 5. The method, as set forth in claim 1, further comprising specifying a 

network intrusion detection application (300, 326) executing on the computer system. 



30 



6. The method, as set forth in claim 1, wherein specifying at least one 
attribute of the specified attack (318) comprises specifying an identification of the 
severity associated with the specified attack. 
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7, The method, as set forth in claim 1, wherein specifying at least one 
attribute of the specified attack (318) comprises specifying a description of the attack 
(300). 

5 8. The method, as set forth in claim 1, wherein specifying at least one 

attribute of the specified attack (3 IS) comprises specifying an explanation of why 
detecting the specified attack is important. 

9. The method, as set forth in claim 1, wherein specifying at least one 
10 attribute of the specified attack comprises specifying how information is to be 

reported (302, 304, 306, 308) to a user with respect to the specified attack. 

10- The method, as set forth in claim 1, wherein specifying at least one 
attribute of the specified attack comprises specifying an application operable to 
1 5 respond to the specified attack (300). 
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